…36466)

When navigator.sendBeacon() is called with a plain string body, the
browser defaults to Content-Type: text/plain;charset=UTF-8. This
causes legitimate WAF alerts because the payload is JSON, not plain
text. Many deployments have been blocking users because of this
mismatch (MM-61530 / #29101).

Fix: wrap the JSON string in a Blob with type 'application/json'
before passing it to sendBeacon. Also add the matching
Content-Type: application/json header to the fallback fetch call
that fires when sendBeacon returns false.

Tests: add three new focused tests in the
PerformanceReporter.sendReport content-type suite that verify:
1. sendBeacon receives a Blob with type application/json
2. The Blob's text content is valid JSON matching the report
3. The fallback fetch includes Content-Type: application/json
Also update the existing (currently skipped) tests to parse the
Blob body via FileReader instead of JSON.parse(string).

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Miguel de la Cruz <mgdelacroix@users.noreply.github.com>

…ttachments (#36468)

Set ReqFileId on the UploadSession created in
  ReceiveSharedChannelAttachmentSyncMsg so the attachment is persisted
  under the sender's file ID. Without this, the receiving server stored
  the bytes under a freshly generated ID while the synced post's FileIds
  still referenced the sender's ID, leaving the attachment invisible in
  the UI even though the file and FileInfo row existed on disk.

  Mirrors the existing cluster-to-cluster path in
  platform/services/sharedchannel/attachment.go.

  Also tightens TestPluginAPIReceiveSharedChannelAttachmentSyncMsg to
  pass a sender-side fi.Id and assert the saved FileInfo keeps it. The
  prior assertion only checked that some ID was assigned, which the
  buggy code also satisfied.